Saltar al contenido principal

Seguimiento de riesgos

SPRINT 2. Semana del 06/03 al 02/04:​

Durante esta semana el equipo ha detectado que se han activado los siguientes riesgos y se han aplicado los correspondientes planes de contingencia:

  • Alta innovación tecnológica.

    • Activación del riesgo: el riesgo se activó el día 15/02 y, a pesar de haber transcurrido ya el primer entregable, sigue activado, debido a que el equipo todavía no se ha terminado de adaptar a las nuevas tecnologías y siguen necesitando formación.
    • Planes de contingencia aplicados:
      • Dedicar tiempo a formación del equipo para poder ejecutar el proyecto con la tecnología que se va a usar. La curva de aprendizaje ha aumentado considerablemente, pero aún se contemplan horas para seguir invirtiéndolas en la formación.
      • Prestar ayuda a aquellos miembros que estén más atascados. Aquellos compañeros que hayan comprendido rápidamente el funcionamiento de la tecnología o que ya la conocieran, ayudan a aquellos que todavía necesiten entender mejor las herramientas.
    • Estado actual: mitigado (29/03). Se da por sentado que el equipo de desarrollo ya comprende el funcionamiento de Angular e Ionic que está usando, ya que se han formado durante el transcurso del sprint 1 y sprint 2.
    • Lecciones aprendidas: el aprendizaje de un nuevo framework puede llevar tiempo al principio, pero, ese tiempo invertido luego ayuda a que los desarrolladores sean más eficientes porque comprenden la tecnología.

  • Tecnología inadecuada al contexto de la aplicación.

    • Activación del riesgo: el riesgo se activó el día 05/03 cuando el desarrollador encargado de hacer la tarea de la gestión del mapa se dio cuenta de que la herramienta Mapbox era complicada de implementar y aumentaba los costes del proyecto de cara al mantenimiento.

    • Planes de contingencia aplicados:

      • Informarse sobre el funcionamiento de otras tecnologías y hacer el cambio. El equipo encontró la librería Leaflet para poder mostrar los mapas. Leaflet es una librería open source que usa JavaScript para mostrar mapas interactivos. La librería es gratuita y es una alternativa idónea tanto para Google Maps como para MapBox.

    • Evaluar si se puede seguir manteniendo parte del código realizado. Analizando el impacto del cambio de tecnología, se concluyó con que era totalmente viable debido a que el equipo no había comenzado apenas a programar la gestión de zonas de aparcamiento, por tanto, no había que desechar código apenas.

    • Estado actual: mitigado (08/03). Tras analizar el impacto, el equipo dio luz verde a la implantación de Leaflet y ejecutó la tarea sin mayor complicación.

    • Lecciones aprendidas: a veces es conveniente detenerse y analizar la viabilidad de las herramientas con las que se va a trabajar, en especial en fases tempranas de desarrollo del software que es un cambio asumible. El hecho de cambiar a una herramienta más simple puede ahorrar mucho tiempo a los desarrolladores.

  • Incapacidad de algún miembro del equipo.

    • Activación del riesgo: el riesgo se activó el día 06/03, debido a que un miembro del equipo no dar su máximo esfuerzo posible por asuntos personales.

    • Planes de contingencia aplicados:

      • Intentar minimizar el impacto con el trabajo de los demás integrantes. El equipo comprendió la situación y ha decidido asumir sin ningún problema las tareas del integrante hasta nuevo aviso.

    • Estado actual: mitigado (08/03). El integrante afectado se encuentra en pleno rendimiento y disponible para seguir con el proyecto.

    • Lecciones aprendidas: es importante tener un plan de contingencia para cualquier tipo de situación y hay que ser empático con los compañeros y ayudarles cuando haga falta.

  • Problemas de coordinación entre grupos.

    • Activación del riesgo: el riesgo se activó el día 05/03, tras tener los coordinadores una reunión de planificación del Sprint 2 en la que se analizó el estado de las tareas del Sprint 1 y el rendimiento de los 3 grupos existentes, se dieron cuenta de que los grupos no terminaban de coordinarse y ser productivos al máximo.

    • Planes de contingencia aplicados:

      • Organización por parte de los coordinadores. Se tomó la decisión de disolver el grupo 2 y repartir a sus integrantes en partes iguales al grupo 1 y 3, que ahora pasaría a ser el nuevo grupo 2.

    • Estado actual: mitigado (08/03). Los dos equipos se han adaptado correctamente a este cambio y funcionan adecuadamente.

    • Lecciones aprendidas: es mejor no subdividir demasiado al grupo, pues sobre todo al inicio la comunicación es crucial.

  • Arquitectura y/o diseño del sistema mal planificado.

    • Activación del riesgo: el riesgo se activó el día 18/03, tras tratar de unificar la sección completa del alquiler de plazas de garajes el equipo detectó que la manera en la que se había estructurado el backend iba a traer problemas para lograr que funcionara correctamente la creación y edición de las imágenes de los garajes.

    • Planes de contingencia aplicados:

      • Evaluar el sistema y generar una modificación del diseño de la aplicación. El equipo afectado analizó el impacto de tanto continuar con la estructura actual como de modificar la estructura del backend para solventar los problemas de integración y determinó que era mejor idea cambiar la estructura del backend para esa tarea, ya que iba a ocupar menor tiempo y que la deuda técnica sería menor.

    • Estado actual: mitigado (29/03). El equipo trabajó arduamente para minimizar el impacto de los cambios aplicados para mejorar la funcionalidad.

    • Lecciones aprendidas: hay que tener un buen diseño se aplicación y programar código pensando en el futuro ya que la deuda técnica puede ser inadmisible en caso de haber tomado una mala decisión.

  • Retraso en alguna tarea y/o sprint.

    • Activación del riesgo: el riesgo se activó el día 30/03, tras comprobar el estado de las tareas y el tiempo restantes del Sprint, se descubrió que habría tareas que se tenían que posponer al siguiente entregable.
    • Planes de contingencia aplicados:
      • Las actividades que no se han realizado, pasarlas al siguiente sprint y ejecutarlas las primeras. Las tareas como el envío de notificaciones al usuario y la puesta de datos de la aplicación se traspasan al siguiente entregable como prioridad máxima.
    • Estado actual: monitoreando. El equipo trabajará duramente para mitigar las tareas lo más rápido posible.
    • Lecciones aprendidas: hay que tener cuidado con el tiempo del que se dispone y saber utilizarlo bien para evitar retrasos.